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Abstract 


We present CO, a parametric calculus for contract-based comput- 
ing in distributed systems. By abstracting from the actual contract 
language, our calculus generalises both the contracts-as-processes and 
contracts-as-formulae paradigms. The calculus features primitives for 
advertising contracts, for reaching agreements, and for querying the 
fulfilment of contracts. Coordination among participants happens via 
multi-party sessions, which are created once agreements are reached. 
We present two instances of our calculus, by modelling contracts as pro- 
cesses in a variant of CCS, and as formulae in a logic. We formally relate 
the two paradigms, through an encoding from contracts-as-formulae 
to contracts-as-processes which ensures that the promises deducible 
in the logical system are exactly those reachable by its encoding as 
a process. Finally, we present a coarse-grained taxonomy of possible 
misbehaviours in contract-oriented systems, and we illustrate them 
with the help of a variety of examples. 


Keywords: contracts, concurrent constraint programming, multiparty 
sessions 


1 Introduction 


The increasing spread and complexity of distributed computing services 
is changing the way services are designed, implemented and exploited. A 
key problem is how to drive safe and fair interactions among distributed 
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participants which are possibly mutually distrusted, and have possibly 
conflicting individual goals. 


Typically, this problem is tackled quite unfairly: service providers fix 
some terms of usage (Service-Level Agreement, SLA), which have to be 
accepted by the client before using the service. SLAs are legal documents, 
written in natural language, normally so long and convoluted that they are 
accepted by default. If a provider infringes its SLA, clients could legally 
prosecute the provider, but the potential costs of a legal action discourage 
clients from taking legal steps, especially when the transaction involves small 
amounts of money. 


Traditionally, SLAs are mostly meant to protect the service provider, 
while the client has to trust that the service correctly implements the required 
functionalities. The acceptance of the SLA has the purpose of freeing the 
service provider from responsibilities in case of hardware and/or software 
hazards, or to avoid costly or impossible tasks. On the other side, service 
providers are rather reluctant to propose SLAs which offer strong guarantees 
to clients. This is quite understandable, since it would require providers to 
certify that their services actually satisfy the promised properties — which 
most often is unfeasible. This situation becomes even more complex when the 
boundary between providers and clients is fuzzy, as it happens for services 
composed together from other services, where the client of a service may be 
the provider of another one. 


Contract-oriented computing is a software design paradigm where the 
interaction between clients and services is disciplined by formal entities, 
named contracts. The life-cycle of a contract-oriented service can be thought 
as composed of three phases. In the first phase, contracts are used to 
negotiate the required and offered behaviour. At the end of this phase, 
contracts may be stipulated: when this happens, the terms of service they 
prescribe become legally binding. In the last phase, services execute their 
tasks. While doing that, they may inspect the contracts they have stipulated, 
to check e.g. what are their current duties, and what has to be expected 
by the other parties. In this framework, enforcing a contract through a 
legal authority has to be considered as a last resort. Typical situations 
would be resolved automatically by the service infrastructure itself, e.g. by 
providing suitable compensations to the injured party, and by inflicting the 
right punishment to the offending party. 


Contracts have been investigated from a variety of perspectives and 
using a variety of different formalisms and analysis techniques, ranging from 
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c-semirings [8, 9, 18], to behavioural types [7, 12, 11, 13], to formulae in 
suitable logics [1, 4, 25], to categories [10], etc. This heterogeneous ecosystem 
of formalisms makes it difficult to understand the essence of those methods, 
and how they are related. 

As a first step towards a unifying framework for reasoning about con- 
tracts we propose a generic calculus for COntract-Oriented computing (in 
short, CO2). By abstracting away from the actual contract language, our 
calculus can encompass a variety of different contract paradigms. We pro- 
vide a common set of primitives for computing with contracts: they allow 
for advertising and querying contracts, for reaching agreements, and for 
fulfilling them with the needed actions. All these primitives are independent 
from the chosen language of contracts, and they only pivot on some general 
requirements fixed in the contract model proposed here. 


Synopsis. Our main contributions are centred around CO2 which is de- 
signed around three main principles. 

The first is the separation of concerns between the way contracts are 
modelled and the way they are used in distributed computations. Indeed, 
we abstract from the actual contract language by only imposing a few 
general requirements. In this way, we envisage our calculus as a generic 
framework which can be tuned by instantiating the contract model to concrete 
formalisations of contracts. In § 2 we present the abstract contract model, 
followed by two concretisations: in § 2.1 we adopt the contracts-as-processes 
paradigm whereby CCS-like processes represent contracts that drive the 
behaviour of distributed participants; in § 2.2 we embrace instead the 
contracts-as-formulae paradigm, by instantiating our calculus with contracts 
expressed in a suitable logic. We relate the two concrete models in § 2.3, 
first with the help of a few examples, and then by showing that contracts-as- 
formulae, expressed in a significant fragment of our logic, can be suitably 
encoded into contracts-as-processes (Theorem 2.7). 

The second design principle of our calculus is that its primitives must be 
reasonably implementable in a distributed setting. To this purpose, we blend 
in § 3 a few primitives inspired by Concurrent Constraint Programming 
(CCP [27]) to other primitives inspired by session types [21]. The key notions 
around which our primitives are conceived are participants and sessions. 
The former represent distributed units of computation that can advertise 
contracts, execute the corresponding operations, and establish/check agree- 
ments. Each agreement corresponds to a fresh session, containing rights and 
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obligations of each stipulating party. Participants use sessions to coordi- 
nate with each other and fulfil their obligations. Also, sessions enable us 
to formulate a general notion of “misbehaviour” which paves the way for 
automatic verification. We suggest possible variants of our primitives and of 
the contract model (§ 3.7). 

The third design principle of CO is that it must allow for modelling 
a wide variety of misbehaviours, specific to contract-oriented systems. Re- 
markably enough, in our approach contracts are not supposed to be always 
respected after they have been stipulated. This motivates the fact that, in 
COz2, contracts are not discharged after they have been used to establish a 
session among a set of participants, as usually done e.g. in the approaches 
dealing with behavioural types. In our approach, contracts are also used to 
drive computations after sessions have been initiated, e.g. to detect if some 
violation has happened, and to identify the responsibles. In § 3.5 we sketch 
a concise taxonomy of what can go wrong in contract-oriented systems, and 
in § 3.6 we present a collection of relevant misbehaviours. 

In § 4 we discuss some related work, and in § 5 we conclude. Appendix A 
contains all the proofs of our statements. 


A simple example. We now give an overview of our proposal with the 
help of a simple example. To do that, we abstract away from the actual 
language for describing contracts: we just illustrate the main features of 
COg, and how contracts are exploited in our framework. 

Consider an on-line marketplace where sellers advertise their products, 
and buyers can shop. In CO, we can specify a system composed by a seller 
A, a buyer B, and a marketplace M as follows: 


representing three distributed participants running in parallel. Within the 
square brackets, the ellipses stand for a process which describes the state 
and behaviour of each participant. 

For instance, assume that the seller first checks that a payment has 
been made, and then ships some goods to the buyer, while the buyer simply 
pays. We informally describe the contracts of A and B as follows: 


Seller contract: ca = “I promise to ship after the buyer has paid” 


Buyer contract: cg = “I promise to pay” 
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The behaviour of A and B can be formalised in CO as: 


Seller behaviour: P 
Buyer behaviour: Q 


(v) tell Jo Ca. asky Ppaia?- do, ship 
(z) tellu lz cp. do, pay 


In their first steps, both seller and buyer advertise their contracts 
(cq and cg, respectively) to the marketplace M. This is done through the 
primitive tell. The effect of telly Jy ca is to move the latent contract |, ca 
to the environment of M. Once the two tell prefixes have been executed, the 
system A[P] | M[---] | B[{Q] becomes: 


(v, 2) (Alasky bpaia?- dov ship] | MUL» ca [zee |---] | Bldo.payl) (1) 


It is important to note that, as long as the contracts are latent (sym- 
bolically, represented by prefixing ca and cg with |), neither A nor B have 
any obligations. As typically done in process calculi, the scope of delimiters 
has been expanded in the system (1). 

Let us now turn our attention to the marketplace M. In our scenario, M 
acts as a brokerage service between sellers and buyers. Indeed, the first step 
of M is to inspect the latent contracts in its environment, in order to find 
agreements among participants. This is modelled by the recursive process 
X © (u) fuse, @.X. The prefix fuse, ¢ looks for a set of latent contracts 
that ensure (at least) a given level of service agreement, described by the 
condition ¢. The actual nature of such conditions, and when contracts satisfy 
them, depend on the contract language adopted (e.g. those described in § 2.1 
and § 2.2). Here we assume that ¢ requires “A ships the goods and B pays”, 
which is satisfied by the contracts ca and cg. Once the fuse, ¢ is executed, 
the system (1) (where the ellipses are replaced by X) evolves to: 


(s)(Alasks &yuiar- dos ship] | M[X] | Bldos pay] | sleales]) (2) 


Basically, the fuse has initiated a new session s among A, B and M, and it 
has moved the contracts ca and cg to the environment of s. Note that in (2) 
these contracts are no longer latent; also, the variables u, v and z involved in 
the latent contracts are now instantiated to the session name s. The shared 
name s allows A and B to coordinate, by accessing the environment of s 
through the primitives ask and do. 

The next step is performed by B, which fires the prefix do, pay. This 
makes the contracts in s adjust themselves to reflect the fact that B has 
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paid. Formally, this is modelled by an LTS on contracts such that ca | 


B does pa ‘ : : 
cg ——~» ce. The contract c represents a situation where A has to ship, 


while B has paid (and so, he has no further obligations). The system (2) 
evolves then to: 


(s)(Alasks dpaiar- dos ship] | M[X] | B[0] | sid) (3) 


Assume that the condition @paiaq? requires that the goods have been paid to 
A. The prefix asks @paid? in A can now be fired, because the contract ¢ in s 
satisfies @paia?. Therefore, the system (3) may evolve to: 


(s)(Aldos ship] | MEX] | B[O] | s{cl) (4) 


The seller can now perform her last action, i.e. shipping the goods. Assume 


A does shi : ae: 
that c —“°*""". ¢, where the contract c’ prescribes no obligations. Then, 


the system (4) finally evolves to: 
(s)(AlO] | MIX] | BI0] | s{¢/) 


The example above shows some of the main features of CO2. However, 
to keep it small, we have not included in the example some distinguished 
features, which we briefly discuss below. 

First, the primitive fuse allows for agreements which involve an arbitrary 
number of participants and contracts. Technically, this is obtained by 
stipulating a minimal set of contracts which satisfy the given condition, and 
then by opening a multiparty session among all the involved participants. 

Second, COg allows for stipulating contracts with multiple levels of 
compliance. Contracts can expose optional behaviours, and the condition @ 
in fuse ¢ ensures a minimal level of “static” agreement. The actual obligations 
of a participant (contained in the contract) may be discovered later on in the 
execution, depending on the other contracts involved in the agreement, and 
possibly also on the actions performed in the session (see e.g. Example 3.4). 

Third, participants are never considered trusted in COg, i.e. we do not 
assume that a stipulated contract is always respected. This makes CO2 
a suitable language for modelling a variety of attacks in contract-oriented 
applications, as shown e.g. by Examples 3.10, 3.11, 3.6, 3.12, and 3.13. Since 
it is not possible, in general, to guarantee that the promises in a contract 
are followed by facts, a minimal safety requirement is that, if some promise 
has not been maintained, then it is possible to identify the responsibles. 
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Our framework allows for identifying, at each step of the execution, who 
is culpable of such violations. Technically, this is done through a relation 
cA between participants and contracts, which has to be specified in each 
instance of the abstract contract model. Intuitively, c/ A means that A has 
no obligations in the contract c. This allows us to specify (in Definition 3.5) 
when a participant is honest in a given context. Roughly, A[P] is honest in 
S when in all fair maximal computations of A[P] | S$, cA holds true for 
all contracts c stipulated by A in the system. The property of being honest 
in all possible contexts is a main design goal for contract-oriented systems, 
because when a participant satisfies it, she is guaranteed that no (honest) 
judge will ever deem her culpable of violations. 


2 An Abstract Contract Model 


Before providing a formal definition, we sketch the basic ingredients of a 
generic contract model. 

We start by introducing some preliminary notions and definitions; 
some of them will only be used later on in § 3. Participants are those 
agents which may advertise contracts, establish agreements, and realise 
them. Sessions are created upon reaching an agreement, and provide the 
context in which participants can interact to fulfil their contracts. Let NV 
and V be countably infinite, disjoint sets of names and variables, respectively. 
Assume N partitioned into two infinite sets Np and Ng, for names of 
participants and of sessions, respectively. Similarly, V is partitioned into two 
infinite sets Vp and Vg, for variable identifiers of participants and sessions. 
A substitution is a partial map o from VY to N; we write u € domo when 
o is defined at u, and require that o maps a € domaM Vp to Np and 
s€domaN Vg to No. 

Our main notational conventions are displayed in Table 1. 

The first ingredient of our contract model is a set A of atoms. Intuitively, 
these will be the basic statements contained in contracts, like e.g. pay and 
ship mentioned in the example in § 1. 

The second ingredient is a set C of contracts. We are quite liberal about 
it: we only require that (7) there exists a set [ of unsigned contracts such 
that A says y € C for all participants A and y €T, and (zi) c| ¢ €C for all 
c,¢ €C. The contract A says y can be thought of as “y signed by A”, while 
c|c’ can be thought as a contract comprising both c and c’. 
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n,m,...EN names, union of: 
A,B,...€ Np participant names 
s,t,... E Ng session names 
Y variables, union of: 
a,b,...€ Vp participant variables 
L,Y,--.€ Vg session variables 
u,v,...ENUYV names or variables 
A, B,...€ Np UVp participant names/variables 
a,a’...€ A atoms 
y7,...ET unsigned contracts 
c,¢,...EC€ contracts (of the form A says 7) 
cle contract comprising c and c’ 
o,y,...E€ ® observables 
Ba SRO LTS on contracts 
Avc A has no obligations in ¢ 
ckK@ c entails ¢ 


Table 1: Notation 


A labelled transition relation OEE Os on contracts models their evolu- 


tion under the actions A does a performed by participants. 


Two further ingredients are a set ® of observables (properties of con- 
tracts) and an entailment relation | between contracts and observables. 
Note that we keep distinct contracts from observables. This has the same 
motivations as the traditional distinction between behaviours (systems) and 
their properties (formulae predicating on behaviours), which brought in 
plenty of advantages in the design/implementation of systems. 


The last ingredient of our contract model is a relation ~ between 
participants and contracts. We write A~c to mean that the contract c 
prescribes no obligations to the participant A. This does not mean that 
A will remain without any obligations while c evolves. Possibly, some 
obligations will arise when some actions are performed by other participants 
involved in c. When AW c is false, we say that A is culpable in c. We require 
that AX c whenever c has no occurrences of A says ---, i.e. A is not culpable 
in contracts where she has not made any statement. 


Definition 2.1 formalises the above concepts. 
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Definition 2.1. A contract model is a tuple (A,C,—», ®, +, ~) where 


e A is a set of atoms. 


e C is a set of contracts, such that (i) ST.VA € Np,y €T. A says 7 €C, 
(ti) Ve, € C.c| cd EC, and (iti) for some signature 4, C forms a 
subalgebra of a term-algebra Tyuy (%). 


A does a . ysis ‘ 
ec —_» ¢d is a labelled transition relation over contracts. 


® is a set of observables, forming a subalgebra of a term-algebra 
Tyun (’) for some signature Dd’. 


e | is a contract entailment relation between C and ®. 


e \ is a contract fulfilment relation between C and participants, such 
that AX c for all c without A says. 


We illustrate the contract model with the help of an informal example. 


Example 2.1. A seller A and a buyer B stipulate a contract co, which binds 


A to ship an item after B has paid. Let pay be the atom which models the 


“pe Bd 
action of paying. The transition cp —~—~—» c, models the evolution of co 


into a contract c; where A is obliged to ship, while B has no more duties. 
Now, let @ be the observable “A must ship”. Then, we would have co ¥ ¢, 
because A does not have to ship anything yet, while c, + 6, because B has 
paid and so A must ship. It would not be the case that AX cy, because B has 
paid, while A has not yet fulfilled her obligation to ship. 


We remark that the use of term-algebras in Definition 2.1 allows us to 
smoothly apply variable substitutions to contracts and observables. Accord- 
ingly, we assume defined the sets var(c) and var(@) of variables of contracts 
and observables. Note that actions are not required to be in C. Including 
them in C would allow for recording the history of the past actions within 
contracts, see e.g. § 2.2. 


2.1 Contracts as Processes 


The first instance of our contract model appeals to the contracts-as-processes 
paradigm. A contract is represented as a CCS-like process [24], the execution 
of which dictates obligations to participants. 
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A contract A says y represents a participant A committed to the 
behaviour specified by the process y. A pending message A)a)B represents 
a message sent on channel a by A, but not received by B yet. A process ¥ is 
a (possibly recursive) composition of prefix-guarded sums of processes. The 
prefixes are the atoms, and they represent silent, input, or output actions. 
Unlike in the standard CCS, input and output prefixes declare not only the 
communication port, but also the intended partner. In an output prefix 
a) A, the participant A denotes the receiver of the message, while in an input 
prefix B)a, B stands for the expected sender. 


Definition 2.2. We define a contracts-as-processes language as follows 


e A is the union of three disjoint sets: the inputs A)a, the outputs a) A, 
and the internal activity 7, where a is a channel name. 


e C is the set of process terms generated by the non-terminal c (the set 
of terms T’ is generated by y): 


eS) | Aja | a)B 
yu= Vion | yiy | x 
= 10 | Asaysy | cle | A)ja)B 


where we assume variables X to be defined through (prefix-guarded 
recursive) equations X &= y. We also denote with 0 the empty sum; 
trailing occurrences of 0 may be omitted. The signature % corresponds 
to the syntax above. 


e —» is the least relation closed under the rules in Figure 1 and structural 
equivalence = (defined with the usual CCS rules and A says 0 = 0). 


e & is a set of terms on a signature d’, including one sort interpreted 
on atoms A (e.g. LTL or CTL formulae). 


e cl @¢ is a decidable relation between the LTS of c and dE ®. 


a ; Ad 
e AXc holds iff fc ,a. c ——=*» ¢. 


We briefly comment on the rules in Figure 1. 

The first row defines an LTS “> for y-processes. The rules are quite 
standard: (PREF) allows for firing an atom, (PAR) for making two y-processes 
evolve in parallel, and (DEF) for expanding a process definition. 
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uo Sy ys 
a.yt+7' 37 (PREF) = : (PAR) ‘= (DEF) 
11142 7% | % Ly 
aB 
Y ae 
(OuT) 
a z 
A says 7 oa. A says y' | A)a)B 
Aja, 
yo 
(IN) 
A 
B says y | A)a)B oe 8 says 
Tr ! A does a ! 
= Cy, 
i mas ! (Tav) : A does a ~ (CPar) 
A says y ————» A says ci | C2 cy, | C2 


Figure 1: Labelled transition relation of contract-as-processes 


The other rules define the LTS —» of contracts, as prescribed by Defi- 
nition 2.1. The rule (OUT) implements an asynchronous output: when the 
contract of A is willing to send a message on channel a to B, the pending 
message A)a)B is put in parallel with the continuation of the contract of A. 
The rule (IN) allows the participant B to perform an input, when a suitable 
pending message is available. Note that the order of output messages is 
not preserved in general. By rule (TAU), a contract willing to perform an 
internal action 7 can do so and exhibit the label A does t. Rule (CPAR) 
makes two contracts evolve in parallel. 

In this paper the actual choice of the set ® and of the relation F is 
almost immaterial. For the sake of the examples we choose for ® the set 
of LTL formulae [17], where the atomic formulae are the atoms in A, and 
+ is Errz where, for all traces 7 of c, the semantics of atoms is defined 
as: nE @ => JA,7’. 1 = (A does a) 7. Decidability of + is ensured 
by restricting contracts to finite control processes [16], i.e. processes where 


parallel composition does not appear under recursion. 

Concerning the fulfillment relation ~, note that a process with an 
output at the toplevel is always culpable, while an input at the toplevel 
makes a process culpable only if the corresponding pending message is 
available. 


Example 2.2. Recall the buyer-seller scenario from Example 2.1. The 
seller A first requires the buyer B to pay, then promises to ship some goods 
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to B. The buyer B promises to pay A, and then to receive the item. Let the 
contracts of A and B be defined as follows: 


ca = A says B)pay. ship)B 
cp = B says pay)A. A)ship 
A possible evolution of the contract ca | cg is then: 
B does pay) 


ca | B says A)ship | B)pay)A 
A does B) pay 
=» 


ca | CB 


A says ship)B | B says A)ship 


Adee she)» A)ship)B | B says A)ship 


B does A)ship 0 
a 


Note that that the buyer contract cg in Example 2.2 is subject to 
attacks. Indeed, A can use a different contract ca allowing her to receive the 
payment without having to perform any other action (cf. Example 3.12). In 
that case, she can legitimately choose not to ship, and still be regarded as 
non culpable. 

Further examples of contracts-as-processes will be provided in 8 3. 


2.2 Contracts as Formulae 


For the second specialization of our generic model, we choose the contract 
logic PCL [4]. A comprehensive presentation of PCL is beyond the scope 
of this paper, so we give here just a brief overview, and we refer the reader 
to [4, 3] for more details. 

PCL extends intuitionistic propositional logic IPC [28] with the con- 
nective —, called contractual implication. Differently from IPC, a contract 
b —» a implies a not only when b is true, like IPC implication, but also in the 
case that a “compatible” contract, e.g. a — b, holds. So, PCL allows for a 
sort of “circular” assume-guarantee reasoning, summarized by the theorem 
+ (b-» a) A (ab) + aAb. Also, PCL is equipped with an indexed lax 
modality _ says _, similarly to [19]. The proof system of PCL extends that 
of IPC with the axioms in Figure 2, while remaining decidable. 

Following Definition 2.1, we now define a contract-as-formulae language 
which builds upon PCL. 
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Ta T 

(¢>4)7¢ 

(Ya 7OrWeb2V)79F >) 
¢ — (A says 6) 

(A says A says ) + A says o 

(¢ > ¥) + (A says 6) > (A says y) 


Figure 2: Hilbert-style proof system of PCL (IPC axioms omitted) 


Definition 2.3. We define a contracts-as-formulae language as follows: 
e A is partitioned in promises, written as a, and facts, written as !a. 

e C=T is the set of PCL formulae, with the following syntax: 
ezx=1l|a|-p|pVp|pAp|prp| pp | Asayse 


We let c| c’ be syntactic sugar forc Ac’. The signature comprises 
the atoms A, all the connectives of PCL, and the _ says _ modality. 


The labelled relation —> is defined by the rule: 


A does a 
c —-»> c| Asaysa | A says !a 


e ®@=C, andy’ =. 


- is the provability relation of PCL. 


Avc holds iff ct A says a implies c+ A says !a, for all promises a. 


Note that the definition of —» allows participants to perform any actions: 
the result is that c is augmented with the corresponding fact !a. We include 
the promise a as well, following the intuition that a fact may safely imply 
the corresponding promise. A participant A fulfils a contract c when all the 
promises a made by A have been followed by the fact !a. 


Example 2.3. The contracts of seller A and buyer B from Example 2.1 can 
be modelled by the following contract-as-formulae: 


ca = A says ((B says pay) — ship) cp = B says pay 
By the proof system of PCL, we have that: 
ca |cp - (A says ship) A (B says pay) 
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Example 2.4. Consider the following variant for the contracts of buyer and 
seller introduced in Example 2.3. 


ca = A says ((B says pay) — ship) 
cp = B says ((A says ship) — pay) 


By the proof system of PCL, we have that: 


ca | cp - (A says ship) A (B says pay) 


2.3. On Contracts-as-Processes vs. Contracts-as-Formulae 


We now compare contracts-as-processes with contracts-as formulae. Our 
main technical result is Theorem 2.7, where we show that contracts-as- 
formulae, expressed in a significant fragment of PCL, can be encoded into 
contracts-as-processes. Finally, we further discuss the differences between 
the two contract models in some specific examples. 

Concretely, we consider a fragment of PCL contracts comprising atoms, 
conjunctions, says, and non-nested (contractual) implications. We call this 
fragment 1N-PCL , after “PCL with 1 level of Nesting of connectives”. Then, 
we provide an encoding of 1N-PCL into contract-as-processes (Definition 2.5) 
and formally relate them. 


Definition 2.4. We define 1N-PCL as the fragment of PCL where formulae 
c have the following syntax: 


Niex A; says Yj 


C 
you= Nez a | (Aiez Bi says bi) > Njeg Aj 
| (ier Bi says bi) + Ajez aj 


Definition 2.5. For all 1N-PCL contracts c and set of participant names 
P, we define the contract-as-process |c|p by the rules in Figure 3. 


We now comment on the equations in Figure 3. All the rules are 
parameterized by a set P of participant names/variables, which is used to 
keep track of the participants mentioned in the contract. The encoding of a 
signed contract A says 7 is just the encoding [y], prefixed with the signature 
A says . The encoding of a conjunction of signed contracts c;, with 7 € Z, is 
the parallel composition of the encodings [c;]. 
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[A A: says 7], = Wier A: sous [nd 

~ieL 

| \ ai], = Pees OUT p(a;) 

ioe 

( \ Bi says b;) —> \ aj] = By)b. o Seca .By)bn. (Iljez OUT p(a;)) 

~4€l.n JET is 

( A\.Bi says bi) > /\ ai], = 7.0 +7.(|licr DEBT (Bi,bi) | \[jer OUT p(ay)) 
~ 4€L JET 


OUTp(a) =7.0 + S- a)A.OUT (a) 
AEP 


DEBT(A,a) = T.DEBT(A,a) + A)a.0 


Figure 3: Mapping from 1N-PCL contracts to contracts-as-processes. 


The encoding of an (unsigned) atom a is the process OUT p(a). This 
process can either perform an internal action and then terminate, or perform 
an output a) A and then return to the initial state. The set P is used to send a 
(non-deterministically) to each participant mentioned in the contract. This 
is to accomodate the explicit receivers of contracts-as-processes with the fact 
that, in 1N-PCL, actions are “broadcasted” to all participants. Note that 
OUT (a) is a recursive process, where an output of a can be performed at each 
recursion. This reconciles the fact that PCL has a non-linear interpretation 
of actions (i.e. once an a is true, it can be “consumed” an arbitrary number 
of times), while contracts-as-processes interpret actions linearly. 

The encoding of an implication (Ajc1,Bi says bi) > Ajezaj is a 
process that first inputs all the premises b,,...,b, from the respective 
senders, and then outputs (in parallel) all the consequences aj. This is done 
through the recursive process OUT (a;) discussed above. Note that the order 
in which the inputs are put is arbitrary. An alternative mapping could be: 


(A Bi says bi) > \ ay] = ING Bibi}ier, {ay}jer) 
ieL GET 


IN(¥,0) = Sree TIN(X\{a},0) if ¥ #0 
llaco OUT p(a) ae ae 


We opted for the simpler encoding, because the order in which inputs 
are executed is immaterial. Indeed, (7) all outputs are asynchronous and 
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replicated, and (71) what matters is that all the inputs have a matching 
output. In other words, it is not important if a blocked input prefix occurs 
before or after another input prefix; the outputs in the consequence of —> 
will not be fired anyway. 

The encoding of a contractual implication (A j-7Bi says bi) > \je7 aj 
is a process which can either perform an internal action and terminate, or 
perform an internal action and continue with the process ||;¢-z DEBT (Bj, b;), 
in parallel with ||;e7 OUT p(a;). The outputs have the same behaviour as 
in the case of standard implication. The process DEBT (B;,b;) waits for an 
input of b;, but while doing so, it may perform internal actions. Therefore, 
the participant who runs a DEBT(B;,b;) is culpable as long as he keeps 
iterating. When the process eventually chooses to perform the input, it is 
no longer culpable. 

Theorem 2.7 below establishes a correspondence between contracts-as- 
formulae and contracts-as-processes. It states that the formulae A says a 
logically entailed by a 1N-PCL contract c exactly correspond to those 
actions labelling the traces of [c] which lead to states where no participants 
are culpable. 

A technical issue is related to “ambiguous” contracts where some atom 
is associated with more than one participant. We rule out this case by 
restricting to non-ambiguous contracts, where instead each atom is said 
by a unique participant. This requires to analyse the contract at hand in 
order to tell, for each atom contained therein, the participant name which 
“binds” it. Technically, this is modelled by the relation 7(c) between atoms 
and participants, introduced in Definition 2.6 below. We shall say that c is 
non-ambiguous iff z(c) is a function. 


Definition 2.6. For all c, we define the relation m(c) € Ax Np UVp as 
follows, where o € {>4,—>}: 


m(f\ Ai says 74) = J ma, (0) 


ieL i€L 
ma( f\ aj) = {(aj,4)) | G€ J} 
JET 
wa(((\ Bi says bi) 0 [\ aj) = {(bi, Bi) | i€ Z}U {(aj,A)) | GET} 
ie JET 


We can now state Theorem 2.7. Its proof is contained in the appendix. 
Note that the non-ambiguity of c is only needed in the “only if” direction. 
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Theorem 2.7. Let c be a non-ambiguous 1N-PCL contract, and let the set 
P include the participant names occurring inc. Then, ck A says a iff: 


In, d, B. (Ide Sa \ (A does 3)B) En A VB! € P. Bcd) 


Example 2.5. Recall the contracts from Example 2.4. According to Defini- 
tion 2.5, we have that: 


[ca | cB] = A says 7.0 + 7.(DEBT(B, pay) | OUT (ship)) | 
B says 7.0 + t.(DEBT(A, ship) | OUT (pay)) 


I g 


where » = (A does t) (B does rT) (A does ship)B) (B does pay)A) 
(A does B)pay) (B does A)ship) (A does 7) (B does 7). This agrees with 
Theorem 2.7, since AX 0 and BY 0. 


Remark 2.1. The contracts-as-processes used in Example 2.2 may sug- 
gest a simpler encoding of — than the one given in Figure 3. For in- 
stance, suppose that — along that direction — we naively encode the formula 
B says (A says ship) —» pay as the following process cp 


cp = B says pay)A. A)ship 


Assume that the context of B is empty, hence it never performs a ship output. 
Then, we have that 


B does pay)A ; 
cB peleell SUM Cp = B says A)ship 
Note that no participant is culpable in cz. The simplified encoding would 
then lead to a countererample to Theorem 2.7. Indeed, such theorem would 
imply 
B says (A says ship) pay | B says pay 

which does not hold in PCL. To solve this problem, the encoding in Defi- 
nition 2.5 guarantees that some participant is culpable until the ship output 
has been performed. 


3 A Calculus for Contract-Oriented Computing 


We now introduce the syntax and semantics of COzg. It generalises the 
contract calculus in [4] by making it independent of the actual contract 
language. In fact, CO2 assumes the abstract model of contracts introduced 
in § 2, which can be instantiated to a variety of actual contract languages. 
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S o:= 0 | A[P| | s{c] | S|S | (u)S 
= dye i) <Soerehi: || P|P | (u)P | X (a) 
CS F | do, a | tell, Ly 7 | ask, 3 @ | fuse, 


Figure 4: Syntax of CO2 


3.1 Syntax 
First, let us define the syntax of CO2. 


Definition 3.1. The abstract syntax of CO is given by the productions in 
Figure 4, where S stands for systems, P for processes, and a for prefixes. 
Also, we write ||ier P; (resp. ||ier S;) for the parallel composition of processes 
(Pi)ier (resp. systems (S;)ier). Further, we stipulate that the following 
conditions always hold: in a system |\ier ni[Pi], ni An; for eachi Aj € I; 
in a process (u)P and a system (u)S, u ¢ Np. 


We distinguish between processes and systems. Systems S consist of a 
set of agents A[P] and of sessions s|c], composed in parallel. Note that A 
and s are names of participants and sessions, respectively. 

Processes P comprise latent contracts, guarded summation, parallel 
composition, scope delimitation, and process identifiers. A latent contract 
ta ¢ represents a contract c which has not been stipulated yet; upon stipu- 
lation, the variable x will be bound to a fresh session name. We allow for 
finite prefix-guarded sums of processes; as usual, we write 71.P, + 1.P> for 
ig12 m;.P;. The empty system and the empty sum are both denoted by 0. 
As usual, we may omit trailing occurrences of 0 in processes. Processes can 
be composed in parallel, and can be put under the scope of binders (u)_. We 
use process identifiers X to express recursive processes, and we assume that 
each identifier has a corresponding defining equation X(u1,..., uj) = P such 
that var(P) C {uy,...,u;} C V and each occurrence of process identifiers 
Y in P is prefix-guarded. Free/bound occurrences of variables/names are 
defined as expected. Variables and session names can be bound; in (w)S all 
free occurrences of u in S are bound. Note that participant names cannot 
be bound, but can be communicated if permitted by the contract language. 
A system S' is closed when it has no free variables. 

Prefixes include the silent prefix 7, action execution do, a, contract 
advertisement tell,, |, y, contract query ask, 3, and contract stipulation 
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commutative monoidal laws for | on processes and systems 
ul(v)P] = (v)u[P] ifuAzv Z| (u)Z’=(u)l(Z| 2’) ifu¢ var(Z) vu fn(Z) 
(u)(v)Z = (v)(u)Z (u)Z=Z ifu¢ var(Z) U fn(Z) 


Inc=0 tell, Jn y-P = 0 ask, c@.P=0 iftoN 40 fuse, ¢.P = 0 


Figure 5: Structural equivalence (Z, Z’ range over systems or processes) 


fuse, @. Note that the contract ¥y in a tell y is unsigned: the correct signature 
A says --- will be attached by the semantics. The index w in tell,, /ask;, 
indicates the target agent/session where the prefix will be fired; in the case 
of fuse,, , it refers to the session where the contracts will be stipulated. 

We shall refer to the set of latent contracts within an agent A[P] as its 
environment; similarly, in a session s{c] we shall refer to c as the environment 
of s. Note that the environment of agents can only contain latent contracts, 
advertised through the primitive tell, while sessions can only contain (non- 
latent) contracts, obtained either upon reaching an agreement with fuse, or 
possibly upon participants performing some do prefixes. 


3.2. Semantics 


The semantics of COg is formalised by a reduction relation on systems which 
relies on the structural congruence laws in Figure 5. Only the last row in 
Figure 5 contains non-standard laws: they allow for collecting garbage terms 
which may possibly arise after variable substitutions. 


Definition 3.2. The binary relation — on closed systems is the smallest 
relation closed under structural congruence and under the rules in Figure 6, 
where the agreement relation K >° $ in (FUSE) will be introduced in Def- 
inition 8.8, and t K is obtained by removing all the | from K, i.e. if 
K = |lier te; ci, then t K = |lier ci. 


We now briefly comment on the rules in Figure 6. 

Rules (TAU), (PAR), (DEL), and (DEF) are standard. Axioms (TELL) 
and (TELL2) state that a participant A can advertise a latent contract |, 7 
either in her own environment, or in a remote one. When the contract 
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A[r.P + P’ | Q| 3 A[P | Q] 
Altellals 7-P +P" | Q] > Alle A says 7 | P | Q] 


Altella te 7-P+P’|Q] | BIR] > A[P| Q] | BIR [Le A says 7] 


A does a ! 
Cs ee 


Aldo,a.P + P’ | Q] | s[c] = A[P | Q] | s[c] 


doma =uCV cat oo 


(ti) (Alasks,z 6.P + P"| Q] | s{e] |S) + A[P| Qlo | s[elo| So 


kpi¢ u=doma CV s =o(«) fresh 


(a) (Alfuses 6.P + P’| K | Q] |S) > (s)(A[P | Qlo | s[t Ko | So) 


X@ =P Pega P 
X (8) > P’ 


sos’ 
S| s" 4 8’ | Ss" 


Ss’ 
(u)S > (u)S’ 


Figure 6: Reduction semantics of CO2 


(Tau) 


(TELL}) 


(TELL2) 


(Do) 


(ASK) 


(FUSE) 


(DEF) 


(PAR) 


(DEL) 
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is advertised, the correct signature A says --- is attached. In (Do), the 
participants A may perform the atom a in session s, provided that the action 
A does a is permitted on the contract in s. Rule (ASK) allows A to check if 
an observable ¢ is entailed by the contracts c in session s; notice that the 
entailment is subject to an instantiation o (possibly empty) of the variables 
mentioned in the ask prefix. Rule (FUSE) establishes a multi-party session s 
among all the parties that reach an agreement on the latent contracts K. 
Roughly, the agreement relation K >° ¢ (Definition 3.3) holds when, upon 
some substitution o, the latent contracts K entail @. 

The simplest typical usage of these primitives is as follows. First, a 
group of participants exchanges latent contracts using tell, hence sharing 
their intentions. Then, one of them opens a new session using the fuse 
primitive. Once this happens, each involved participant A can inspect the 
session using ask, hence discovering her actual duties within that session: in 
general, these depend not only on the contract advertised by A, but also on 
those of the other participants (see e.g. Example 3.4). Finally, the primitive 
do is used to actually perform the duties. 


Example 3.1. The sale scenario between seller A and buyer B from Exam- 
ple 2.3 can be formalized as follows. 


S = Al(a,b) tellals ((b says pay) > ship). fuse, (A says ship). do, ship] 
| Bi(y) tella Ly pay. doy pay] 


The buyer tells A a contract which binds B to pay, and eventually does that. 
A session between the buyer and the seller is created and proceeds smoothly 
as expected, as shown in the trace in Figure 7. 


In the previous example, we have modelled the buyer-seller system by 
using a contracts-as-formulae approach. In the following example, we adopt 
instead the contracts-as-processes paradigm. In the meanwhile, we introduce 
a further participant to our system: a broker C which collects the contracts 
from A and B, and then uses a fuse to find when an agreement is possible. 


Example 3.2. Recall the contracts of Example 2.2. We specify the behaviour 
of the system as follows, where observables are expressed in LTL: 


def 


S = Al(a,b)tellc (Le b)pay.ship)b). do, b)pay. do, ship)b| 
| B{(y)tellc 1, pay)A. do, pay)A. do, A)ship | 
| 


C[ (z, a, b) fuse, © (pay)a A Oship)b) | 
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S —+ (a,b,y) (Alla A says ((b says pay) — ship) | 
fuse, (A says ship). do, ship] 
| Bitella | pay. doy pay] ) 
— + (2,b,y) (Ally B says pay | le A says ((b says pay) — ship) | 


fuse, (A says ship). do, ship] 
| Bido, pay] ) 
—+ (s) (Aldo, ship] 
B 


do, pay| 
s[A says ((B says pay) —> ship) | B says pay] ) 


— > (s) (A[0] 

B[do, pay] 

s[A says ((B says pay) — ship) | B says pay | A says !ship | ...] ) 
— (s) (A[0] 

B[0] 


s[A says ((B says pay) > ship) | B says pay | 
A says !ship | B says !pay | ...] 


Figure 7: A trace of the system in Example 3.1 


The participants A and B advertise their contracts to the broker C, which 
opens a session for their interaction. The broker checks that the buyer 
declares that he will eventually pay, and that the seller declares that she will 
eventually ship. As expected, 


S —+* (s) (A[0] | B[O] | s{0]) 


namely, as soon as the payment is received, the goods are shipped. 


3.3. On Agreements 


To give semantics to fuse, @ we instantiate in Definition 3.3 below the relation 
_&, -, which establishes when a set of latent contracts can be stipulated. 
Roughly, K > @ states that the latent contracts in K satisfy ¢, according 
to the relation - of the contract model. More formally, Definition 3.3 
accommodates the variables in K and in @ as well as it enables the creation 
of the session for the evolution of the stipulated contracts. Notably, in this 
way we allow for agreements among an arbitrary number of participants 
(modulo a minimality condition explained below). 
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Definition 3.3. For all parallel compositions K of latent contracts, for all 
substitutions 0: V 4 N, for all x € V, and for all observables ¢, we write 
Ke? ¢ iff the following conditions hold: 


e x € domo 


e var(Ko) = var(do) = 0 


e dse Ng: Vy € domaN Vg: a(y) =s 
° (t K)ot 60 
e noo’ Coa satisfies the conditions above, i.e. o is minimal. 


The first four items in Definition 3.3 state that an agreement is reached 
when the latent contracts in K entail, under a suitable substitution, an 
observable ¢@. Recall that ¢ is the condition used by the participant acting 
as broker when searching for an agreement (cf. rule (FUSE) in Figure 6). 
The substitution o has to instantiate all the variables appearing in the latent 
contracts K as well as the session variable x; the latter, together with any 
other session variables in the domain of o, is mapped to a session name s. 
The freshness of s is guaranteed by the rule (Fuse). 

The last item in Definition 3.3, i.e. the minimality condition on a, allows 
brokers to tell apart unrelated contracts. For instance, let lz, c1, lz, C2, and 
{xz €3 be the latent contracts advertised to a broker; if there is an agreement 
on Jr, C1 and Jz. C2, the latent contract |, c3 would not be included. This 
is illustrated by the following informal example. 


Example 3.3. Let @ be the observable “A shall ship the goods”, and consider 
the following latent contracts, advertised by A, B, and C, respectively: 


ele, G1 = “in session x1, if b pays, then I shall ship the goods” 

@ fr. C2 = “in session x2, I shall pay” 

© trz C3 = “in session x3, I shall kiss a frog”. 
Note that the first two latent contracts do entail ¢ when o(b) = B, and 
o(%1) = o(x42) = s. Without the minimality condition, o(a3) = s could 


have been included in the agreement of A and B, despite the offer of C being 
somewhat immaterial. 
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The following example shows that our approach allows for agreements 
with multiple levels of compliance. 


Example 3.4. Let ca, cp,, and cp, be the following contracts-as-formulae: 


ca = A says ((b says pay) — ship A (b says coupon) > gift) 
cp, = Bi says pay 


cp, = Be says pay A coupon 


Now, consider the following system composed of a seller A, which also acts 
as a broker, and two buyers By and Bg: 


A [(z, b) telly Le ca. fusex (b says pay). 
(ask, !pay. doz ship | ask; !coupon. doz gift) | 
| Bil[(y) tella ly cp,. doy pay] 
| Bo[(z) tella |. cp,. do, pay. do, coupon] 


The seller contract ca is compliant with both cg, and cp,, t.e. both buyers 
can be put in a session with A. When coupled with cp,, the contract ca 
entails both the obligations ship and gift for A. When coupled with cp,, we 
obtain a weaker agreement, as only the obligation ship is entailed. Although 
both levels of agreement are possible, in some sense the contract cp, yields 
a tighter Service-Level Agreement than cp,. The seller A detects the actual 
service level she has to provide through the primitive ask . 


3.4 On Honesty 


In Definition 3.5 below we set out when a participant A is honest in a given 
system Sj, i.e. she always respects all the promises made. More in detail, 
we consider all the possible runs of S, and require that in every session the 
participant A eventually is not culpable. To this aim, we shall exploit the 
fulfilment relation AY c from the contract model. 

Before defining honesty, we need to cope with a few technical issues. 
First, the a-conversion of session names makes it hard to track the same 
session at different points in a trace. So, we consider traces without a- 
conversion of session names, formalized as the LTS ~~ in Definition 3.4. 


Definition 3.4. For all systems S, we define the function freezey(S) as: 


freezey(S) ={S" | S=(s1,...,8;)S’ and S’ delimitation-free} 


Contract-Oriented Computing in CO, 29 


where a system is delimitation-free if it does not contain delimitations of 
session names. We define the LTS ~» on systems as 


Sw Ss" iff SS" and S" € freezey;(S") 


We say that a ~»-trace (5;); is maximal iff it is either infinite, or it ends in 
a state S;, such that Sp, %. 


Another technical issue is that a participant could not get a chance to 
act in all the traces (see e.g. Example 3.17. To account for this fact, we will 
check the honesty of a participant in fair traces, only, i.e. those obtained 
by running S' according to a fair scheduling algorithm. More precisely, a 
~»-trace (.S;); is fair if no single prefix is enabled in an infinite number of S;. 


Definition 3.5. A participant A is honest in S iff for all maximal fair 
~»-traces (Sj); 


Vs. Jj. Vi> i, it, c, 8’. (s:= (#)(slq | S) = Acc) 


In other words, a participant A misbehaves if involved in a session s 
such that the contracts c of s do not settle the obligations of A. 


3.5 What Can Go Wrong in Contract-Oriented Systems? 


Contract-oriented systems are a subclass of distributed systems where the 
interaction among participants is based on the principle that “every promise 
must be kept”. Of course, since the goals of the participants are possibly 
conflicting, and since systems resemble “the condition of mere nature, which 
is a condition of war of every man against every man” [20], this principle 
is not expected to be always obeyed in practice. Indeed, contract-oriented 
systems are characterised by a variety of possible misbehaviours and attacks, 
in part inherited from real-world issues in legal contracts, in part specific to 
(concurrent and distributed) software systems. 

We outline below a coarse-grained taxonomy of possible misbehaviours 
in contract-oriented systems, where the participant A plays the role of the 
injured party. Associated to each issue in the taxonomy, we enumerate a 
(non-exhaustive) list of possible causes. We will do that rather informally, by 
appealing to the reader intuition, to be reinforced in § 3.6 with the help of 
a collection of relevant examples. Roughly, below we say that “A succeeds” 
in a session when the goals of A (either implicitly known to A, or explicitly 


30 


M. Bartoletti, E. Tuosto, R. Zunino 


written in her contract) have been performed by the other participants 
involved in that session. We say that “A is protected” when, in each possible 
interaction, either A succeeds or someone else is culpable. 


In Table 2 we summarize our taxonomy, and we point out some links 
to relevant CO2 examples which may be found in the following section. 


Agreement issues The participant A has advertised the contract c, but 
she is never placed in a session where c has been stipulated. 


Li, 


The contract c is over-protective for A: if stipulated by B, then 
A would be protected, while B would not. 


. The contracts advertised by the other participants do not guar- 


antee the success of A. 


3. The broker is over-protective (for one or more of the participants). 


4. Fairness problems: even though the contract of A could be stipu- 


lated, the broker never includes A in a session. 


Success issues The participant A participates in a session, but she does 
not succeed. 


Li 


Some participant does not fulfil his contract, and he is considered 
culpable. 


. The contract of A is not strong enough to protect A: no participant 


is culpable. 


. The contract of A is strong enough to protect A, but the broker 


puts A in a session with participants which do not guarantee that 
the goal of A will be reached. 


. The contract of A is strong enough to protect A, but A performs 


unprotected actions. 


. Fairness problems: other participants cannot perform their duties 


because of unfair scheduling. 


Culpability issues The participant A participates in a session where she 
tries to respect her contract c with the best intentions, but she is 
eventually considered culpable of a violation of c. 


dt, 


A relies on some other participant B to fulfil some of her duties, 
but B has “passed the buck” to A. 
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Agreement issues 


Cause Contracts-as-formulae | Contracts-as-processes 
Over-protective A Ex. 3.5 Ex. 3.5 
No success guarantee Ex. 3.6 (similar) 
Over-protective broker fuse L Ex. 3.7 
Fairness problems Ex. 3.8 Ex. 3.9 


Success issues 


Cause Contracts-as-formulae | Contracts-as-processes 
Someone else culpable Ex. 3.10 (similar) 
Contract too weak Ex. 3.11 (similar) 
Deceptive broker Ex. 3.13 Ex. 3.12 
Unprotected actions Ex. 3.14 (similar) 
Fairness problems (similar) Ex. 3.15 


Culpability issues 


Cause Contracts-as-formulae | Contracts-as-processes 
Pass the buck (similar) Ex. 3.16 
Fairness problems Ex. 3.17 (similar) 


Table 2: Issues in contract-oriented systems. 


2. Fairness problems: A cannot fulfil her contract because of unfair 
scheduling. 


? 


A main design principle of CO is that it must allow for writing “wrong’ 
specifications of systems which exhibit these kinds of misbehaviour and 
attacks. This is the reason why COz2 does not prevent (almost) any actions in 
the semantics. In particular: (7) participants can advertise whatever contracts 
they wish, the only condition being that these can be expressed in the contract 
model; (ii) contract brokers can stipulate arbitrary contracts, and create 
sessions with an arbitrary number of participants; (iii) participants can 
perform whatever action in a session, if permitted in the current state of the 
contract in that session. 


3.6 A Collection of Misbehaviours and Attacks 


In this section we collect a set of archetypal contract-oriented scenarios, 
which use contracts from both paradigms introduced in § 2.1 and § 2.2. Each 
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of the scenarios discussed below highlights one of the causes of misbehaviour 
reported in the taxonomy in § 3.5. 


Example 3.5. Consider a variation of the system S in Example 3.1 where 
the buyer process is modified as follows: 


Bi(a, y) tella Ly ((a says ship) — pay). ask, (a says !ship). do, pay] 
Now, the fuse in A has to entail A says ship from the contract: 
A says (B says pay) > ship | B says (A says ship) > pay 


Note that both participants require the other one to “make the first step”. 
This circular dependency forbid any agreement. A similar behaviour can be 
modelled as follows, using contracts-as-processes: 


A says B)pay. ship)B_ | B says A)ship. pay)A 


Example 3.6. Consider a variation of the buyer-seller system, where the 
buyer and seller contracts are: 


ca = ((b says pay) + snakeOil) 
cp = (a says ship) — pay 


and the processes are as follows: 


A|(a, b) tella ta ca. fuse, (A says snakeOil). do, snakeOil] 
Bi(a, y) tella ly cp. asky (B says pay). do, pay] 


The interaction between the fraudulent seller A and the buyer B gets 
stuck on the fuse in A, because the available latent contracts do not en- 
tail A says snakeOil. Note that we have used contractual implication —, 
rather than standard implication +. This would have allowed B to reach an 
agreement with the seller contract (b says pay) — ship. 


Example 3.7. Consider the following variant of Example 3.4, using 
contracts-Qs-pTrocesses: 

ca = A says ( B)pay. ship)B | B)coupon. gift)B ) 

cp = B says pay)A. ( 7. A)ship + 7. Coupon)A. A)ship. A)gift ) 
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Now, assume that ca and cg are advertised to a broker, which wants to 
establish an agreement through a fuse ¢, with ¢ = ©(pay)A A coupon) A). 
The broker will not be able to put A and B together in a session, because the 
contract cg allows B to choose whether consuming the coupon or not. Instead, 
the broker would be able to establish the weaker agreement o' = Opay)A. 


Example 3.8. Consider the system: 
S = A[Xo] | BLXa] | CEX] | K[Y] 


where, for 1 € 0..2, X; e (x;)tellk Le, C1.Xi, Y = (z)fuse, d.Y, and ¢ is 
satisfied by any c; | cj withi Aj. An unfair scheduler could always choose 
the contracts of B and C, and neglect those of A. 


Example 3.9. Consider the following contracts-as-processes for the buyer- 
seller scenario: 


def 


ca = X X 27.X +B)pay.Y Y 2+ +ship)B 
cp = Z | A)ship Z27Z+payyA 


Assume that the broker attempts to establish a session between A and B 
through fused, with @ = ©(pay)A A Oship)B). Without any fairness as- 
sumptions, ca | cp /irz >, because an unfair scheduler can choose e.g. to 
never fire the prefix pay)A, even though this prefix is enabled infinitely often. 


Example 3.10. Consider a variation of the system S' in Example 3.1 where 
the seller process is modified as follows: 


A|(x, b) tella a ((b says pay) — ship). fuse, (A says ship). 0] 


The fraudulent seller A promises to ship, but it does not act accordingly and 
simply terminates. The interaction between A and B leads to the system: 


(s) (A[0] | B[O] | s[A says ((B says pay) > ship), B says pay, B says !pay]) 


where the buyer has not obtained what he has paid for. However, the 
insuccess of the buyer is partially mitigated by the fact that the seller is found 
responsible of this misbehaviour. Indeed, the seller is dishonest according 
to Definition 8.5, because the contracts in s entail the promise A says ship, 
while the fact A says !ship is not present in the session. A judge may thus 
eventually punish A for her misconduct. 
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Example 3.11. Recall Example 3.10 and consider a fraudulent seller A, 
which promises in her contract some snake oil: 


ca = ((b says pay) > snakeOil) 
while the contract and the behaviour of B are as in Example 3.1. Then: 


S = Al(z,b) tella le ca. fusez (A says snakeOil). doz snakeOil] | BI: - -] 
—+* (s) (A[0] | B[O] | s[A says !snakeOil, B says !pay, ...]) 


In this case the interaction between A and B goes unhappily for B: he will 
pay for some snake oil, while A is not even classified as dishonest according 
to Definition 3.5: indeed, A has eventually fulfilled all her promises. The 
cause of this misbehaviour is that the buyer contract is too weak for being 
used with untrusted participants. 


Example 3.12. Recall the buyer-seller scenario from Example 2.2. We 
slightly modify the seller contract as follows, while cg stays the same: 


ca = A says b)pay.(r + ship)b) 


The seller A first requires the buyer to pay, then promises either to ship an 
item, or to do nothing. A possible evolution of the contract ca | cp, where 
the participant name B substitutes for the participant variable b, is then: 


B does pay)A 
——» 


(ca | cp) {B/d} ca | B says A)ship | B)pay)A 


Bae) PY. A says (r + ship)B) | B says A)ship 


BOT K says 0 | B says A)ship 
The contract of B is rather naive, because the buyer pays without requiring 
any guarantee to the seller. Indeed, in the final state c’' = B says A)ship, we 
have that AX c’, i.e. A is not culpable. Now, consider the following system, 
composed of a buyer A, a seller B, and a broker C: 


S = Al[(z,b) (tellc Lx ca. dor b)pay. (r + do, ship)b)) | 
| Bl (y) (tellc Ly cp. doy pay) A. do, A)ship) | 
| C[(z,d) fuse, O(pay)d) | 


The broker C, which opens a session between A and B. Notice that C is rather 
unfair, since it only checks that the buyer will eventually pay, while it does 
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not require that the seller will eventually ship. The seller can then choose 
to perform the internal action T, instead of shipping the paid item, while 
remaining not culpable. We have the following (maximal) computation: 


S —* (s) (A[0] | B[do, A)ship] | s[0]) 
where B has not succeeded, but neither A nor C are considered culpable. 


Example 3.13. Consider the following formalization of the system in Ex- 
ample 3.12, using contract-as-formulae: 


A|(a, b)tellc {x ((b says pay) — (ship V fraud)). doz fraud] 


B[(y, a)tellc Ly ((a says ship) —» pay). asky B says pay. doy pay] 
C[(z)fuse, | 


where the formula @ is chosen so to make the fuse in C pass (this can be 
obtained e.g. by taking the conjunction of the contracts of A and B). Unlike 
in Example 8.12, even if a session between A and B is established by the 
deceptive broker, the buyer will not pay, and he will not be considered culpable 
for that. Indeed, the prefix ask, B says pay is stuck because the contracts in 
the session do not entail any obligation for B to pay. 


Example 3.14. Consider the following variant of Example 8.13, where the 
buyer process is modified as follows: 


Bi(y, a)tellc ly ((a says ship) —» pay). doy pay] 


Although the contract of B is strong enough to protect B, this protection is 
lost when the buyer performs the action pay without checking beforehand 
(through ask, B says pay) that he actually has to pay. This imprudence leads 
B to a situation where he does not succeed, while A is not considered culpable. 


Example 3.15. Consider a variant of the buyer-seller system in Exam- 
ple 3.2, where the seller behaviour is modified as follows: 


A[ (a, 6) (tellc (Le b)pay.ship)b). do, b)pay.X]  X “7.X + do, ship)b 
Even though the prefix do, ship)b is enabled infinitely often, an unfair process- 
level scheduler could prevent A from eventually shipping. A similar misbe- 
haviour can be obtained through an unfair system-level scheduler. Note that 
in Definition 8.5, we do not consider dishonest the participants which fail to 
fulfil their duties because of an unfair scheduling. 
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Example 3.16. Consider the following variant of the buyer-seller scenario. 
The seller A advertises a contract where she promises to provide the buyer b 
with a proof-of-shipment (PoS) if b pays (pay). After the buyer has paid, 
the seller advertises a contract to a broker K, where she looks for a carrier c 
which provides A with a proof-of-shipment if A pays shipping (payS). 


A[ (x, y, b,c) tella Lx (b) pay. PoS)b). fuse, b says pay)A. do, b)pay. P| 
P = tellx |, (payS)c.c)PoS). doy payS)c. do, c)PoS. do, PoS)b 
B[(y) tella |, (Pay)A. A)PoS). do, pay)A. do, A)PoS] 


Now, assume that the contract between buyer and seller has been stipulated, 
and that the buyer has paid. If no carrier is found to stipulate the contract 
with A, then the seller will be considered culpable of a violation, because she 
has not honoured her promise to provide the buyer with a proof-of-shipment. 


Example 3.17. Consider the system S = Aldo; pay] | B[LX] | S’, where 


Vas 7.X, and S" contains a session where the action of A is enabled. Note 


that S generates the infinite trace S ~~» S ~~ S ~>--- in which A never pays, 
despite her honest intention. According to Definition 8.5, participant A is 
considered honest. 


3.7 Variants to the Basic Calculus 


We mention below a few variants and extensions of CQg. 


Protection for contracts-as-processes. The contracts-as-processes 
model can be adapted to allow participants to defend against attacks carried 
over by deceptive brokers, like the one shown in Example 3.12. The variant 
requires the semantics of fuse ¢ to be changed so that contractual obligations 
derive only from mutually compliant contracts, i.e. c/ @ should hold only 
when all the (fair) traces of c lead to 0, in addition to c Ezrz ¢. Similarly, 
Ac should also hold on non-mutually-compliant c, since in this case no 
obligation arises. With this change, even if a participant A is somehow put 
in a session with fraudulent parties, A can discover (via ask) that no actual 
obligation is present, so avoiding to perform unprotected actions. 


Local actions. In COs, agents A[P] only carry latent contracts in P. 
Hence, communication between participants is limited to latent contract 
exchange. Allowing general data exchange in CO2 can be done in a natural 
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way by following CCP. Basically, P would include CCP constraints t, ranging 
over a constraint system (7,1), a further parameter to CO2. Assume that 
A says t € T for all ¢ € T and for all A. The following rules will augment 
the semantics of COz2 (the syntax is extended accordingly): 


A[tella t.P + P’ | Q] > AIA says t | P| Q] 
Altellg t.P + P’ | Q] | BIR] > A[P | Q] | BIA says t | Bl 
Alaskat.P + P’|T|Q] > A[P|T|Q]_ provided that TF t 


Note that the above semantics does not allow A to corrupt the constraint 
store of B augmenting it with arbitrary constraints. Indeed, exchanged data 
is automatically tagged on reception with the name of the sender. So, in the 
worst case, a malicious A can only insert garbage A says t into the constraint 
store of B. 


Retracting latent contracts. A retract primitive could allow a partici- 
pant A to remove a latent contract of hers after its advertisement. Therefore, 
A could change her mind until her latent contract is actually used to establish 
a session, where A is bound to her duties. Of course a contract cannot be 
retracted after it has been agreed upon. 


Consistency check. The usual check ¢ primitive from CCP, which checks 
the consistency of the constraint store with ¢t, can also be added to COg. 
When check t is executed by a participant A[P], t is checked for consistency 
against the constraints in P. Note that checking the whole world would be 
unfeasible in a distributed system. 


Forwarding latent contracts. A forward primitive could allow a broker 
A to move a latent contract from her environment to that of another broker 
B, without tagging it with A says . In this way A delegates to B the actual 
opening of a session. 


Remote queries. More primitives to access the remote participants could 
be added. Note however that while it would be easy e.g. to allow Alaskg ¢] 
to query the constraint of B, this would probably be undesirable for security 
reasons. Ideally, B should be allowed to express whether A can access his 
own constraint store. This requires some access control mechanism. 
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4 Related Work 


Contracts have been used at different levels of abstraction, and with different 
purposes. A coarse classification of the approaches appeared in the literature 
separates the approaches that use contracts to model the possible inter- 
action patterns of services, from those where contracts are used to model 
Service Level Agreements. In the former category, the typical goal is that of 
composing services only if their interactions enjoy progress properties (e.g. 
deadlock-freedom). In the latter, the goal is that of matching clients and 
services, so that they agree on the respective rights and obligations. 

Multi-party session types [22] are integrated in [6] with decidable frag- 
ments of first-order logic (e.g., Presburger arithmetic) to transfer the design- 
by-contract of object-oriented programming to the design of distributed 
interactions. We follow a methodologically opposite direction. In fact, in [6] 
one starts from a global assertion (that is global choreography decorated 
with logical assertions) to arrive to a set of local assertions; distributed pro- 
cesses abiding by local assertions are guaranteed to have correct interactions. 
In our framework, a participant declares its contract independently of the 
others and then advertises it; a COz primitive (fuse ) tries then to harmonise 
contracts by searching for a suitable agreement. In other words, one could 
think of our approach as based on orchestration rather than choreography. 
The same considerations above apply to [23]; there protocols (state machines 
with memory) represent global choreographies and contracts are represented 
as parallel state machines (according to a CSP-like semantics). Basically, 
the contract model of [23] coincides with its choreography model. 

Global assertions in [6] enable for the automatic generation of monitors. 
At a first glance, this looks similar to our use of contracts as driver of the 
computation. However, a main difference is that the monitors synthesised 
from global assertions have a “local” view of the computation as they 
basically check the incoming messages of a distributed component. Instead 
in CQO2, the contracts stipulated in a session form a “global view” of the 
(current) evolution of the computation. This enables us to formalise a notion 
of honesty (cf. Definition 3.5) and single out culpable components during 
the computation. We argue that it would be hard to attain the same within 
the approach in [6]. For instance, a monitor obtained from a global assertion 
can check for an incoming message m from a partner A; however the monitor 
cannot distinguish if the absence of m is due to a violation the contract of 
A, or due to the fact that other duties (possibly from other participants) 
required by A are not accomplished. In other words, the monitor cannot 
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deem A culpable. 


An advantage of the approach in [6] is that projecting a global assertion 
yields local assertions, that is the contracts of each component in the chore- 
ography. Using local assertions one can check if a component A abide by its 
contract LD, namely if A realises L. In our framework this is more complex 
to be achieved since abstracting away from contracts makes it hard to give 
a general notion of “realisability”. 


In cc-pi [9], CCP is mixed with communication via name fusion so 
that parties establish SLA by merging the constraints representing their 
requirements. Constraints are values in a c-semiring advertised in a global 
store. It is not permitted to merge constraints making the global store 
inconsistent, since an agreement cannot be reached in that case. Conversely, 
COs envisages contracts as binding promises rather than requirements. Ac- 
tually, even if a participant A tells an absurdum, this will result in a contract 
like: “A is stating a contradiction” added to the environment. When this 
happens, our approach is not “contracts are inconsistent, do not open a ses- 
sion”, but rather “A is promising the impossible, she will not be able to keep 
her promise, and she will be blamed for that”. The cc-pi calculus is further 
developed in [8] to include long running transactions and compensations. 
There, besides the global store, the calculus features a local store for each 
transaction. Local inconsistencies are then used to trigger compensations. 
In CO2, compensations do not represent exceptional behaviour; they fall 
within “normal” behaviour and have to be spelt out inside contracts. In- 
deed, after a session has been established, each honest participant A either 
maintains her promises, or she is culpable of a violation; A cannot simply try 
to execute arbitrary compensations in place of the due actions. Of course, 
other participants may deem her promise too weak and avoid establishing a 
session with A. 


In [15] a calculus is proposed to model SLAs which combines z-calculus 
communication, concurrent constraints, and sessions. There, the constraint 
store is global and sessions are established between two processes whenever 
the stated requirements are consistent. Interaction in sessions happens 
through communication and label branching/selection. A type system is 
provided to guarantee safe communication, although not ensuring progress. 
Essentially, the main role of constraints in this calculus is that of driving 
session establishment. Instead, in COg the contracts of an agreement leading 
to a session are still relevant e.g. to detect violations. 


In [14], contracts are modelled in a fragment of CCS which includes 
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prefixing, internal/external choice, and recursion. This model is not directly 
comparable with our CCS-like model in § 2.1: while our contracts do not 
feature external choice, they have parallel composition and synchronization. 
The notion of compliance between two contracts used in [14] is “boolean”: 
either the client contract is compliant with the service contract, or it is 
not. In Example 3.4 we show that our approach allows for a “multi-level” 
notion of compliance, encompassing more than two contracts. In [14], 
contracts which are not compliant may become compliant by adjusting the 
order of asynchronous actions. When this is possible, an orchestrator can 
be synthesised from the client and service contracts. In some sense, the 
orchestrator acts as an “adapter” between the client and the service. In our 
approach, the orchestrator behaves as a “planner” which finds a suitable 
set of contracts and puts in a session all the participants involved in these 
contracts. 


Our approach differs from those discussed above, as well as from all the 
other approaches we are aware of (e.g. [7, 12, 13]), w.r.t. two general principles. 
First, we depart from the common principle that contracts are always 
respected after their stipulation. We represent instead the more realistic 
situation where promises are not always maintained. As a consequence, 
in CO2 we do not discard contracts after they have been used to couple 
services and put them in a session, as done e.g. in all the approaches dealing 
with behavioural types. In our approach, contracts are also used to drive 
computations after sessions have been established (cf.§ 3), e.g. to detect 
violations and to provide the agreed compensations. 


The second general difference is that CO2 smoothly allows for handling 
contracts-as-processes (cf. § 2.1). To the best of our knowledge, it seems 
hard to accommodate these contracts within frameworks based on constraint 
systems ((5, 15]), logics ([4, 6]), or c-semirings (e.g. [9, 8, 18]). 

The contract-as-formulae model proposed here hinges on PCL ’s contrac- 
tual implication to handle the intrinsic circularity present in contracts. This 
is motivated by the fact that the standard intuitionistic implication would 
fall short in modelling (circular) require-guarantee conditions to participants 
in distributed systems. Some relations between PCL and other logics are 
reported in [3]. 

A recent research direction is modelling contracts as formulae in suitable 
deontic logics [26]. We argue that those approaches are complementary to 
ours. On the one hand, deontic logics are more suitable than PCL to model 
the dynamic execution of contracts (e.g., to assign blame to participants 
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and to provide reparations to contract violations). On the other hand, 
PCL targets more directly the problem of finding agreements, especially in 
presence of circular dependencies among the participant requirements. 


The present paper extends and enhances prior work appeared in [2, 4, 5]. 
The calculi presented in [4, 5] were hard-wired to the PCL contract model, 
and they did not explicitly keep apart promises from facts. Instead, CO2 
distinguishes between promises (latent contracts, advertised through a tell 
prefix) and facts (actions performed through a do prefix), so allowing us to 
give a general definition of when a participant is honest in a given context 
(Definition 3.5). Also, the calculi in [4, 5] recorded contracts into a global 
constraint store, while COg has local environments for participants and 
sessions. This makes COg amenable to possible distributed implementations. 


With respect to [2], the main improvements concern the contracts-as- 
processes model, and its relation with contracts-as-formulae. More precisely, 
in the current paper (7) contracts explicitly mention the participants from 
which they expect to receive an input / send an output, (iz) outputs are asyn- 
chronous, using an implicit buffer with unbounded capacity which preserves 
no ordering among outputs, and (iii) there is a stronger correspondence 
result between contracts-as-formulae and contracts-as-processes. 


The feature (7) allows for a finer-grain design of contracts-as-processes. 
For instance, instead of just requiring “if someone pays, then I will ship”, 
explicit senders/receivers allow for modelling the contract “if B pays, then I 
will ship to B”, specified formally as A says B)pay.ship)B. Also, (i) helps in 
improving the precision of the correspondence between contracts-as-processes 
and 1N-PCL contracts, which natively feature explicit senders through the 
says in the antecedent of +/—. 


The feature (77) allows for a definition of culpability which is fairer w.r.t. 
that in [2]. For instance, assume that A promises to pay (i.e. she outputs 
pay), while B promises to receive the payment (i.e. he inputs pay). Consider 
the situation were A exposes the output prefix of pay, but B does not expose 
the corresponding input prefix. In [2], communication is synchronous, and a 
participant is culpable until it reaches the state 0: therefore, both A and 
B are considered culpable. This is quite unfair for A, who after all has 
attempted to fulfil her duties. Also the converse situation, where A has not 
paid and B is stuck on the input, is unfair in [2]: this time B is considered 
culpable, even if he is just waiting that A has fulfilled her duties. In the 
current paper, instead, when A wants to pay she can do it asynchronously; 
B will be culpable until he eventually performs the input. Conversely, when 
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A has not paid and B is stuck on the input, B will not be culpable. 

The correspondence result between contracts-as-formulae and contracts- 
as-processes featured in this paper is more precise than the result in [2]. The 
encoding in [2] guarantees that a 1N-PCL contract c logically entails all the 
atoms contained in c iff its encoding [c] can reach the state 0. The encoding 
presented here (Definition 2.5) guarantees a stronger result. Roughly, a 
1N-PCL contract c logically entails some atom a iff its encoding |c] has 
a trace containing a, and leading to a state where all participants are not 
culpable (Theorem 2.7). 

While taking inspiration from Concurrent Constraint Programming, 
CO» makes use of more concrete communication primitives which do not 
assume a global constraint store, so reducing the gap towards a possible 
distributed implementation. The main differences between CO2 and CCP 
are: (i) in CO constraints are contracts, (iz) in COz there is no global store 
of constraints: all the prefixes act on a local environment, (iti) the prefix ask 
of CO2 may instantiate variables to names, and (iv) the prefixes do (which 
makes contracts evolve) and fuse (which establishes a new session) have no 
counterpart in CCP. 


5 Conclusions 


We have developed a formal model for reasoning about contract-oriented 
distributed programs. The overall contribution of this paper is a contract 
calculus (COz ) that is parametric in the choice of contract model. In COs, 
participants can advertise their own contracts, find other participants with 
compatible contracts, and establish a new multi-party session with those 
which comply with the global contract. We have set out two crucial issues: 
how to reach agreements, and how to detect violations. We have presented 
two concretisations of the abstract contract model. The first is an instance 
of the contracts-as-processes paradigm, while the second is an instance of 
the contracts-as-processes paradigm. 

We envision a methodology where one uses contract-as-formulae at 
design-time, reasons about them through the contract logic, and then concre- 
tises them at run-time to contracts-as-processes. As a first step towards this 
goal, we have related contract-as-processes and contracts-as-formulae, by 
devising a mapping from contracts based on the logic PCL [4] into CCS-like 
contracts. Theorem 2.7 guarantees that contracts-as-processes can reach 
success in those cases where an agreement would be possible in the logic 
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model, hence providing a connection between the two worlds. 

The correspondence result established by Theorem 2.7 may be refined 
in two directions. First, while the goal of the current encoding is to preserve 
the entailment, one could also focus on precisely preserving the culpability 
of participants. Note e.g. that the encoding of B says (A says a) — b in 
Definition 2.5 makes it possible to perform b “on credit”. However, this 
results in B being culpable because of the DEBT(B,b) process. In order to 
precisely preserve culpability, the encoding should instead make A culpable, 
since she has to “pay” the debt. Still, the current encoding preserves a weak 
form of culpability, i.e. the fact that some participant is culpable. This is 
enough to establish the correspondence in Theorem 2.7. 

A second direction for refining the encoding is to preserve some corre- 
spondence property in all the traces of the contract-as-process. This seems 
to suggest to exploit reversibility techniques, i.e. by assuming that all the 
actions can be undone, and then by undoing those traces which do not lead 
to a successful state. Note in passing that Theorem 2.7 guarantees that at 
least one property-preserving trace exists. Yet, this is enough to preserve 
agreements. For instance, assume that fuse (A says a) finds an agreement 
in a PCL contract c. Then, it is possible to reach an agreement also with 
[c]. This is obtained through a fuse ¢, where ¢ requires that there exists 
some trace of [c] where (7) A does a)B eventually holds (for some B), and 
after that (iz) no participant is culpable. Such ¢ can be expressed e.g. in 
the branching temporal logic EF. 


Acknowledgements 


We thank the anonymous reviewers for their valuable suggestions and com- 
ments which helped us in improving the paper. 

This work has been partially supported by the Aut. Region of Sar- 
dinia under grants L.R.7/2007 CRP2-120 (Project TESLA) and CRP-17285 
(Project TRICS), and by the Leverhulme Trust Programme Award “Tracing 
Networks” . 


References 
[1] Alexander Artikis, Marek J. Sergot, and Jeremy V. Pitt. Specifying 


norm-governed computational societies. ACM Trans. Comput. Log., 
10(1), 2009. 


44 


M. Bartoletti, E. Tuosto, R. Zunino 


[2] Massimo Bartoletti, Emilio Tuosto, and Roberto Zunino. Contracts 


[12 


— 


in distributed systems. In ICE, volume 59 of EPTCS, pages 130-147, 
2011. 


Massimo Bartoletti and Roberto Zunino. A logic for contracts. Technical 
Report DISI-09-034, DISI - Universita di Trento, 2009. 


Massimo Bartoletti and Roberto Zunino. A calculus of contracting 
processes. In LICS, pages 332-341. IEEE Computer Society, 2010. 


Massimo Bartoletti and Roberto Zunino. Primitives for contract-based 
synchronization. In ICE, volume 38 of EPTCS, pages 67-82, 2010. 


Laura Bocchi, Kohei Honda, Emilio Tuosto, and Nobuko Yoshida. A 
theory of design-by-contract for distributed multiparty interactions. In 
CONCUR, volume 6269 of Lecture Notes in Computer Science, pages 
162-176. Springer, 2010. 


Mario Bravetti and Gianluigi Zavattaro. Towards a unifying theory 
for choreography conformance and contract compliance. In Software 
Composition, volume 4829 of Lecture Notes in Computer Science, pages 
34-50. Springer, 2007. 


Maria Grazia Buscemi and Hernan C. Melgratti. Transactional service 
level agreement. In TGC, volume 4912 of Lecture Notes in Computer 
Science, pages 124-139. Springer, 2007. 


Maria Grazia Buscemi and Ugo Montanari. CC-Pi: A constraint-based 
language for specifying service level agreements. In ESOP, volume 4421 
of Lecture Notes in Computer Science, pages 18-32. Springer, 2007. 


Felice Cardone. The geometry and algebra of commitment. In Ludics, 
dialogue and interaction, pages 147-160. Springer, 2011. 


Samuele Carpineti, Giuseppe Castagna, Cosimo Laneve, and Luca 
Padovani. A formal account of contracts for web services. In WS-F'M, 
volume 4184 of Lecture Notes in Computer Science, pages 148-162. 
Springer, 2006. 


Samuele Carpineti and Cosimo Laneve. A basic contract language for 
web services. In ESOP, volume 3924 of Lecture Notes in Computer 
Science, pages 197-213. Springer, 2006. 


Contract-Oriented Computing in CO, 45 


[13] 


[14] 


[15] 


[24] 


Giuseppe Castagna, Nils Gesbert, and Luca Padovani. A theory of con- 
tracts for web services. ACM Transactions on Programming Languages 
and Systems, 31(5), 2009. 


Giuseppe Castagna and Luca Padovani. Contracts for mobile processes. 
In Proc. CONCUR, volume 5710 of Lecture Notes in Computer Science, 
pages 211-228. Springer, 2009. 


Mario Coppo and Mariangiola Dezani-Ciancaglini. Structured commu- 
nications with concurrent constraints. In TGC, volume 5474 of Lecture 
Notes in Computer Science, pages 104-125. Springer, 2008. 


Mads Dam. On the Decidability of Process Equivalences for the z- 
calculus. Theoretical Computer Science, 183(2):215-228, 1997. 


E. Allen Emerson. Temporal and modal logic. In Handbook of Theoretical 
Computer Science, Volume B: Formal Models and Sematics (B), pages 
995-1072. North-Holland Pub. Co./MIT Press, 1990. 


Gian Luigi Ferrari and Alberto Lluch-Lafuente. A logic for graphs with 
QoS. Electr. Notes Theor. Comput. S'ci., 142:143-160, 2006. 


Deepak Garg and Martin Abadi. A modal deconstruction of access 
control logics. In FoSSaCS, volume 4962 of Lecture Notes in Computer 
Science, pages 216-230. Springer, 2008. 


Thomas Hobbes. Leviathan or The Matter, Forme and Power of a 
Common Wealth Ecclesiasticall and Civil. 1651. Chapter XIV — Of 
the first and second natural laws, and of contracts. 


Kohei Honda, Vasco T. Vasconcelos, and Makoto Kubo. Language 
primitives and type disciplines for structured communication-based 
programming. In ESOP, volume 1381, 1998. 


Kohei Honda, Nobuko Yoshida, and Marco Carbone. Multiparty asyn- 
chronous session types. In POPL, pages 273-284. ACM, 2008. 


Ashley T. McNeile. Protocol contracts with application to choreographed 
multiparty collaborations. Service Oriented Computing and Applications, 
4(2):109-136, 2010. 


Robin Milner. Communication and concurrency. Prentice-Hall, Inc., 
1989. 


46 M. Bartoletti, E. Tuosto, R. Zunino 


[25] Cristian Prisacariu and Gerardo Schneider. A formal language for 
electronic contracts. In FMOODS, volume 4468 of Lecture Notes in 
Computer Science, pages 174-189. Springer, 2007. 


[26] Cristian Prisacariu and Gerardo Schneider. A dynamic deontic logic for 
complex contracts. The Journal of Logic and Algebraic Programming 
(JLAP), 81(4):458-490, 2012. 


[27] Vijay Saraswat, Prakash Panangaden, and Martin Rinard. Semantic 
foundations of concurrent constraint programming. In POPL, pages 
333-352, 1991. 


[28] Anne Troelstra and Dirk van Dalen. Constructivism in Mathematics, 
vol. 1. North-Holland, 1988. 


Contract-Oriented Computing in CO, 47 


A Proofs 
Notation. Hereafter, for c,c’ contracts-as-formulae, we write c,c’ for cA c’. 


Definition A.1. The Gentzen-style sequent calculus of PCL is defined by 
the rules in Figure 8. 


As proved in [4], the sequent calculus of PCL enjoys cut elimination. A 
cut on a formula p is replaced by cuts on strict subformulae of p, and cuts 
on p having a shorter proof tree. This makes PCL decidable. 


Theorem A.2 (Cut Elimination [4]). If p is provable in PCL, then there 
exists a proof of p not using the (Cut) rule. 


Definition A.3. Let u be the homomorphic function from PCL formulae 
to PCL formulae such that u(A says p) = u(p). We say that a formula c 
is says -free 1N-PCL when there exists some c! in 1N-PCL such that 
= Ue ). 


Lemma A.4. For all says -free 1N-PCL formulae c, and foro € {>,—-}: 
caobt c= crc V c,aobFt a,b,c 


Proof. By Theorem A.2, consider a proof tree A of c,aob Ft c without 
occurrences of the (Cur) rule. The RHS of each sequent in A has the form 
(ier ai, and so A only contains occurrences of the rules (Ip), (AL1), (AL2), 
(AR), (3L), (Fix). There are two cases, according to the choice for o. 


e o=-—. If the rule (=L) has never been used in A, consider the proof 
tree A’ obtained by replacing each T,a > b+ pin A with TF p. Since 
there is no other rule in those mentioned above which can use > in 
the LHS, then A’ proves ct c. 


Otherwise, if A contains an occurrence of the rule (+L), then one of 


its premises must be c,a > bF a. By the rule (-L), we have: 


c,a—bbra c,a—>b,bF b 
c,a—b-Eb 


e o=-». If the rule (Fix) has never been used in A, consider the proof 
tree A’ obtained by replacing each T,a > b+ pin A with TF p. Since 
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T,poqet T, p> 4q, Er Te E 
Pp an = oe (3L) Pp q (>R) 


T,p>qatp T,p>qaat 6 


ee saree: (PREPOST) 


T,p>qartp Tprmaqtktr 


PT, pq r ee 


[+ p [, A says p,p | A says q 
[+ A says p (oaeSk) T,A says p + A says q 


(SaysL) 


Figure 8: Genzten-style proof system for PCL. 
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there is no other rule in those mentioned above which can use — in 
the LHS, then A’ proves cf c. 


Otherwise, if there exists an occurrence of the rule (Fix), then its 
premise contains the entailment c,a — b,rt a, for some r. By case 
analysis on the rules (Ip), (AL1), (AL2), (AR), (-L), (Fix), it follows 
that, for all T, I’, p,q, if [| p and I’ q belong to A, then I and I” 
are logically equivalent. Therefore, c,a —» b,r is logically equivalent to 
c,a — b, that is to say c,a — bl a. To conclude, by the rule (Frx): 


c,a—b,bFa c,a—b,bF b 
ca bk b 


Definition A.5. Let 7: A— NpUYVp. We define the partial function 
Sx() from unsigned says -free1N-PCL formulae to 1N-PCL formulae as 
follows: 


sx( /\ = \\ Pr(yi) says i 


1EL 1EL 
\ m(a;) says a; fy= /\\ aj 
sly) = 4 957 1A 
Py (7) says (se(/\bi) Ayer as) if y= (Abdio A aj 


iEeL 1eL JET 


where o € {-+,-»}, and P,(y) is defined as follows: 


P.( \ aj) = A if N9-€ Je Tag SA 
jeg undefined otherwise 
Pr((A\bi) 0 /\ az) = Pel (\ ay) 
iEL GET GET 


Lemma A.6. For all PCL formulae p,q, if pt q then u(p) - u(q). 


Proof. Straightforward by induction on the derivation of pt q. 


Lemma A.7. Let 7: A> NpUYp. For all says -free 1N-PCL formulae 
canda=f\,<,;a; such that s,(c) is defined: 


cha <> s7(c) s_(a) 
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Proof. To prove the (=) direction, assume that cf a. By Theorem A.2, 
consider a proof tree A of ct a without occurrences of the (Cur) rule. The 
RHS of each sequent in A has the form A. a;, with J C J, and so A only 
contains occurrences of the rules (Ip), (AL1), (AL2), (AR), (-L), (Frx). We 
have the following cases, according to the last rule used in A: 


e (Ip). We have that c = c’,a, and rule (Ip) has been instantiated as: 


cata 
The thesis follows trivially by s,(a) F s,(a). 
e (AL1). We have that c = p Aq, and the instance of rule (AL1) is: 


CDANGD Pe 
c.pAqkta 


By the induction hypothesis, 
sx(¢), Sx(pAq),8n(p) F S2(a) 
Since s,(p A q) © Sx(p) A 8n(q), by (AL1) we conclude: 


Sx(C), 8a(p) A 82(), Sa(p) F Sx(@) 
Sx(C’), 8x(p) A Sx(q) F Sx (a) 


from which the thesis follows by using the same observation. 


e (AL2). Similar to the previous case. 
e (AR). We have that a = p Aq, and the instance of rule (AR) is: 
crp ckega@ 
cr pAqg 


By the induction hypothesis (twice), s;(c) F s,(p) and s,(c) F s;(q). 
Therefore, by (AR): 


Sx(c)F 8x(p) Sn (c) F $8x(Q) 
8x (€) F 8x(p) A Sx(q) 


and the thesis follows because s,(p) A 87(q) © S82(pA q) = Sx(a@). 
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¢ (L). We have that c= c',p — q, with p = A; bj and q = /\;a;. The 
instance of rule (—L) is: 


Cy Pp ep ageg ho 
c,poqta 


By the induction hypothesis, applied twice: 


Sr(C), Sx(p > q) F 8x(p) (5) 
Sr(C),Sx(p > @)s8a(@) Faz (a) (6) 


By Definition A.5, 


Sx(p + q) = Px(p - ) says (8x(p) + [\ aj) 
j 


Since P,(q) = P;(p — q) is defined by hypothesis, and since 


A says (p’ 3 q) 7 (p' > A says q) 


A says \ai + |\A says aj 
j j 


are theorems in PCL , we have that: 
Sx(c’), 8n(p + q) F Sx(p) + Sx(q) (7) 
By (7) and (5), it follows that: 
Sx(c'), 8x(p) + $x(q) F x(q) 
Together with (6), we conclude that: 
sx(C), 8n(p 3 q) F Sq(a) 


e (Fix). We have that c= c',p — q, with p= J; b; and q= Nj aj. The 
instance of rule (Fix) is: 


c.p>qgatp cdp»aqaqka 
d,p>qka 
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By the induction hypothesis, applied twice: 


Sr(¢), 8a(p > @), S2(a) F sx(p) (8) 
sx(¢), Sx(p ~ q), 8x(q) F Sq(a) (9) 


By Definition A.5, 


Sx(p -» q) = Pr(p > q) says (sx(p) » /\ aj) 
j 


Since P,(q) = P;(p — q) is defined by hypothesis, and since 


A says \ai & \\A says aj (10) 
J j 


is a theorem in PCL, we have that q+ s,(q), and so by (9): 
Sx(c’), 8x(p » q),q F Sx(a) (11) 
By (9) and (11), it follows that: 


8x (Cc), 82(p > gq), + Sx(p) (12) 


By Definition A.5, s;(p > q) = P,(q) says (sx(p) - q). Now, since 
p— A says p is a theorem in PCL, by (12) it follows that: 


Sx(c'), 8x(p) » G,¢ F 8x(p) (13) 


Therefore, by rule (SaysL): 


13 I 
ce -,8n(p) ag F ies 
“1Sr(p) mG Fg 
(SaysR) 
-, Pr(q) says (82(p) — q), Sx(p) » @ | Pr(q) says q (14) 


87(c), Pr(q) says (S(p) » q) F Pr(q) says q 


Now, since P;(q) = P;(p — q) is defined and because of (10), we have 
that P,(q) says q © s,(q). Also, by Definition A.5, 


P,(q) says (Sx(p)  @) = Sx(p > @) 
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We can then rewrite (14) as: 
Sr(C'), Sx(p > q) F Sx(q) 
Together with (9), this gives the thesis: 


Sx(C'), 8x(p > q) F 8q(a) 


To prove the (<) direction, assume that s,(c) F s,;(a). By Lemma A.6, we 
have that u(s,(c)) F u(s,(a)). The thesis follows by noting that u(s,(c)) = c, 
and u(s,(a)) =a. 


Definition A.8. For all traces n of a contract-as-process c, we define the 
set of LN-PCL actions act(n) as follows: 


tf) ifn is empty 
act(n) = ¢ act(n’) ifn = (A says B)a) 1! 
{A says a} U act(n’) ifn = (A says a) B) 1! 


Notation. Hereafter, to indicate any contract c such that AX c for all A, 
we sometimes just write ~. We write A)a) for a pending message where the 
receiver is immaterial. 


Lemma A.9. For all 1N-PCL contracts c, if 
[ce] | || ;ep DEBT (Bi, bs) | lier Asdas) hy me 


then 


C, \ A; says aj; + act(n), \ B; says b; 
jes iel 


Proof. We proceed by induction on the length of 7. 

To keep the proof succinct, we make some mild simplifying assumptions 
on the form of the contract c. More precisely, we assume that in conjunctions 
\ jez aj, the set J is always a singleton (we do not make this assumption 
for the antecedent of + and -»). The proof for the general case can be 
easily obtained from the current one, at the cost of some extra details in the 
management of conjunctions. 

In the base case 7 is empty, and so act(n) = @. Since, by hypothesis, 


Av ||,<p DEBT (Bi, b;) for all A, then it must be the case that I = @: by 
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contradiction, if this were not the case and 7 € I, we would have that 

the participant who says DEBT (B;,b;) = 7. DEBT (B;,b;) +--- is culpable. 

Therefore, the base case requires to prove that c,---' @, which holds trivially. 
For the inductive case, let 


co = [c] | || ,<- DEBT (Bi, bi) | lle yAsdas) 


and assume a trace: 


A says a n! Ae 
CQ, ee. LE, Sere 


where 7 = (A says a)n’. We have the following exhaustive cases, obtained 
by analysing the possible choices for the first transition. 
1. c=d,A says a, transition by the rule (Tau) on [a] = OUT (a). Then: 


Co Aste T, [e’] | llc PEBT (Bi, bi) | ies Aidan) 


The thesis follows directly from the induction hypothesis. 


2. c=c',A says a, transition by the rule (Our) on [a] = OUT (a). Then, 
a = 4)B for some B, and: 


A says a)B 
co =» [ed] | OUT(a) | A)a)B | ||,<)DEBT (Bi, bi) | || ¢As)ay) 


= [¢, al | A)a )B | || ,<- DEBT (Bi, bi) | ll jer Asdas) 
By the induction hypothesis, it follows that: 


c, A says a, /\ 4; says aj -F act(n Oe he says bj (15) 
jEd tel 


By the rule (Ip), c/ A says a. Then: 


C, | 4; says a; + A says a, act(n Oy Bi says b; 
jEed tel 


and to conclude it suffices to note that act(7) = {A says a} U act(r/’). 


3. ¢ = C,(Anet.n Dn says dn) > b, transition by the rule (In) on the 
leftmost input of [(Aj;e1.» Da says dn) > bj]. This requires that a 
suitable pending message is available in co, i.e. there exists 7; € J such 
that Aj;,)a;,) = Di)di) A. There are two subcases. 


Contract-Oriented Computing in CO, 55 


e ifn =1, then: 


A says D)d 
co SS» [ed] | OUT (b) | ||, DEBT (Bi, bi) | || 4; 4s) s) 
jEI\{hr} 


/ 
= [c,b] | ||,<p DEBT (Bi, bj) | ergy Aides) 
By the induction hypothesis, we have that: 
oF \ A; says a; / act(r/), \ B; says b; 
JEST\ {ha} ier 

The above entailment is weakened to: 

ce, (Di says di) + b, Dy says di, \ A; says aj 

jEI\{ji} 
Now, since A;, = D; and aj, = dj, the above is equivalent to: 
ce, (D1 says d\) + b, \ Aj says aj + 
jEed 
from which the thesis follows, because act(7) = act(n’). 
e ifn > 1, then: 


A D;)d 
gy es ell lp DEBT BB) 


Dg)do. is 1D eles | eatin} 4a)49) 
= [¢,(Ane2.n Dh says dn) — b] | 
lier DEBT (Bi, bi) | lieu} 4adas) 
By the induction hypothesis, we have that: 
é, (A Dh, says dp) > b, \ A; says a; + act(7’), | Bi says b; 
h€2..n JEI\ {ii} ic] 
The above entailment can be weakened as follows: 
e (/\ Dp, says d;,) + b, Dy says dy, \ A; says aj fF 
h€2..n JEI\{ji} 
which is equivalent to: 


¢, (/\ Dj, says dn) > b, Dy says di, \ A; says aj 
h€l..n JEI\{r} 
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Now, since A;, = D; and aj, = dj, the above is equivalent to: 


é, (A Dh, says dp) > b, aS A; says aj F 
hel..n jEd 


from which the thesis follows, because act(n) = act(7’). 


4.c=C,(Aney Dn says dp) — b, transition by the rule (Tav) on the 
leftmost 7 of [(Aj,e7 Dn says d;,) — b]. Then: 


Co mila [c’] | lic DEBT (Bi, bi) | Nica s)@0) 


By the induction hypothesis, we have that: 
é, \ A; saysa; + act(r/), \ B; says b; 
jeJ iel 
Since act(7) = act(n’), to conclude it suffices to weaken the entailment: 


G. \ A; says aj; + act(n), \ B; says b; 
jeJ i€l 


5. c= ¢,(Apney Dh says d;,) — b, transition by the rule (Tav) on the 
rightmost 7 of [(A,cH Dn says dp) — b]. Then: 


A 
co >t» [el] 


ney PEBT (Dp, dn) | OUT (b) | 
N.er DEBT (Bi, bs) | [pes 
= [eb] | ||,¢;-DEBT (Dn, da) | 

lier PEBT (Bi, bi) | |] jis) 
By the induction hypothesis, we have that: 


c, b, \ A; says a; + act(r’), \ Dp, says dp, \ Bi says b; (16) 
jed heH ie 


The above entailment can be weakened as follows: 


é, /\\ Aj says aj, (A Dp, says dn)  b, b FE /\\ Dp, says dp (17) 
jEed heH heH 
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Also, by the rule (Ip) we have that: 


¢, \ Aj says aj, (A Dh, says dn) » b, b F b (18) 
jes heH 


Therefore, by the rule (Frx) it follows that: 


(17) (18) 
C, Nje Aj says aj, (Anew Dh says dn) > br b 


(FIx) (19) 


Since act(7) = act(n’), (16) and (19) allow to obtain the thesis: 


cd, ( \ Dy), says dp) — b, \ A; says aj; / act(n), Bi says bj 
heH jed i€l 


. Transition by the rule (Tav) on DEBT (By, bx), for some k € I. Then: 


A says T 
(6 cree cco & 0) 


and the induction hypothesis gives the thesis. 


. Transition by the rule (Our) on DEBT (By, bx), for some k € I. This 
requires that a suitable pending message is available in co, i.e. there 
exists h € J such that A;,)ap,) = By)b,)A. Then: 


A says By) br 
> 


CO [e1 | Hier\ {aj DEBT (Bi, bi) | leary Aida) 


By the induction hypothesis, we have that: 
é, /\\ A; saysa; - act(r/’), \ B; says b; 
jeJ\{h} iel\{k} 


By weakening the entailment, the above is equivalent to: 


c, \ A; says a; + act(7’), /\\ B; says b; 
jed ic I\{k} 
Now, since A, says aj, = By, says by, by the rule (Ip) we obtain: 


é, \ A; saysa; + act(r/), /\ B; says b; 
jeJ icl 


and the thesis follows because act(7) = act(7’). 
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Lemma A.10. For all 1N-PCL contracts c such that [els 4, d and 
A says 3)B € n, we have that B € P, and either d has the form d' | 
A says OUT p(a), or there exists some 1! with A says a)B € 1 such that 


le], ii, d| A says OUT p(a). 


Proof. We proceed by induction on the length of 7. 

In the base case, 7 necessarily consists of A says a)B. Hence, the 
thesis trivially follows by construction since [e] must be of the form c’ | 
A says OUTp(a) with B € P so d’ = c' | A)a)B | A says OUTp(a) (by 
rules (REC), (OUT), and (PAR) in Figure 1). 


For the inductive case, let 7 = 7, A says a)B n2 with A says a)B ¢ np. 


A a)B 
Namely, assume that |c RS dy al Se dg “P.. d. Note that dy 
P 


has the form d | A says OUTp(a) and recall that A says OUTp(a) = 
T.0+ > pep a) B.A says OUT p(a). 

If d is not of the form d’ | A says OUT p(a) then there must be a state 
da” reached through 72 where the 7 transition of A says OUT p(a) is taken. 
Removing such transition from 72 would give another trace 7 from dz where 
all states are the same as those in 7) in parallel with A says OUT p(a), which 
gives the thesis. 


Definition A.11. We say that a participant A is in charge of a in state co 
: A says a 
if ¢c. ———>. 


Lemma A.12. Let c be a non-ambiguous 1N-PCL contract, and let the 
set P include the participant names occurring inc. If ch A says a, then: 


An, d. ( [lp A A says a€ act(n) A VB EP. Bed) 


Proof. Since c is non-ambiguous, then by Definition 2.6 there exists a function 
m7 = 1(c) which maps each atom in c to a single participant. Since ct 
A says a by hypothesis, then 7(a) = A. Let c; be a says -free 1N-PCL 
formula such that c = s,(c,). Since s,(c,) / s;(a), then by Lemma A.7 it 
follows that cj Fk a. By repeated applications of Lemma A.4, we can write c; 
as C,,C, for some c, and c’ such that ¢, + b for all atoms b occurring in c,, 
and cy, a. W.1.o.g. we can assume such c, to be minimal, so that removing 
a formula from it would prevent the entailment of some atom. 
By observing that: 


[eles > [sx (ci) |» = [sx (cu) ]p | [se(€) |p 
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we show the thesis by exhibiting a trace where all the steps are due to the 
subprocess [sie (Gn) | as while [se(€) |p stays idle. The trace of [sr (cu)] is 
then constructed as follows: 


P 


e First, we consider the contractual implications of c,. Let cy = 
Cy Sx((Aj_1 bi) > b),... where c’, is free from —». In the encoding of 
each —, we fire the second rT: we therefore have 


— saysT x 
SS 


[cul eae | z(b) says (OuTp(b ) | (ae DEBT (x(b,), b:)) l siete 


This basically makes available in the contract all the outputs b which 
occur as a consequence of a contractual implication, at the cost of 
introducing the associated debts. 


e Then, using all the OUT p(b) in the context, including those we have 
spawned above, we fire all the inputs in the encoding of the (standard) 
implications of c\,, hence spawning outputs for their consequences, as 
well. Unlike for the contractual implications, this requires to follow a 
precise ordering, namely the ordering in which implications would be 
eliminated in a proof of their consequence. For instance, for a,,a, > 
a2,a2 — ag we would use a, to fire the inputs of aj — ao, and only 
then use ag to fire the inputs of ag — ag. In the general case, a correct 
order of such implications always exists, since otherwise we would have 
a circular dependency between some implications, some of which would 
then be redundant to entail some atom, and hence it would not belong 
to C, which is minimal. 


This shows that 


[cu] p = leule | 
m(b) says (OUTp(b) )| ||, DEBT (m(b;), bi) | OUT p(c) | -- Na 


where the c’s denote the consequences of the implications. 


e Above we made available all the OUT p(b) for any b in c,. These allow 
us to fire all the inputs of all the DEBT (7(b;),b;), so making them 
move to 0. 


e Having removed the encoding of implications, contractual implications, 
and debts, now only the OUT p(b) remain, for any b in c,. We can 
then make them output all their atoms, so that they occur in 7, and 
then make them move to d= 0, so that we can have B~d for any B. 
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The trace generated above indeed includes all the entailed atoms. 


Theorem 2.7. Let c be a non-ambiguous 1N-PCL contract, and let the 
set P include the participant names occurring in c. Then, cf A says a iff: 


An, d, B. (Ide ”, @ - (A does 3)B) €n A VB' EP. Bod) 


Proof. The “only if” direction follows from Lemma A.9, by substituting the 
empty set for J and J. The “if” direction follows from Lemma A.12. 
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